Sortie du langage Go en version 1.6

Posté par  . Édité par esdeem, Davy Defaud, Lucas, Benoît Sibaud, M5oul, claudex et palm123. Modéré par patrick_g. Licence CC By‑SA.
72
20
fév.
2016
Golang

Go est un langage libre créé par Rob Pike (UTF-8), Ken Thompson (Unix) et Robert Griesemer (V8) dont le but était de « régler les problèmes de Google ». Il se retrouve finalement apte à résoudre des problèmes bien plus divers.

Go est un langage compilé à typage statique, dont l’objectif est de rester le plus simple possible tout en incluant les fonctionnalités indispensables d’aujourd’hui : réseau, concurrence, Unicode, ramasse‐miettes, outils de développement…

À titre d’exemple, un serveur Web avec la bibliothèque standard se résume à quelques lignes :

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hi there, I love %s!", r.URL.Path[1:])
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Sommaire

Description

Cette simplicité dans la syntaxe s’accompagne de quelques fonctionnalités propres détaillées ci‐dessous.

Les goroutines

Une instruction du langage go func() permet de lancer une fonction en concurrence de manière très légère, on peut en lancer des milliers, réparties automatiquement sur plusieurs fils d’exécution (threads) ou cœurs.

Les channels

Pour synchroniser les différentes goroutines, il est possible soit d’utiliser des mécanismes classiques de verrous soit des channels. Des canaux à travers lesquels les goroutines s’envoient des objets typés.

package main

import "fmt"

func sum(x, y int, c chan int) {
    c <- x + y
}

func main() {
    c := make(chan int)
    go sum(24, 18, c)
    fmt.Println(<-c)
}

Interfaces et composition

Il n’y a pas de classes en Go. On utilise des interfaces qui définissent un ensemble de méthodes sur un objet. Un type implémente une interface lorsqu’il implémente toutes les fonctions définies par cette interface. Le compilateur se charge de cette vérification automatiquement.

Il n’y a pas d’héritage, les types (interfaces et structures comprises) peuvent être composés.

defer

L’instruction defer permet de lancer une fonction à la fin de la fonction qui le contient, pour fermer un fichier par exemple.

Les outils

Les outils standards facilitent grandement le travail et le partage de code :

  • gofmt permet de formater le code de manière conventionnelle ;
  • go run permet de compiler et lancer un programme immédiatement à la manière d’un langage interprété ; il n’y a besoin ni de fichier include ni de makefile ;
  • go get permet d’installer un paquet (la gestion des versions de paquets est en cours de standardisation).

Nouveautés de la version 1.6

Changements au niveau du langage

Aucun ! Merci, la dépêche est terminée vous pouvez changer d’onglet.

C’est une promesse tenue, la compatibilité ascendante est conservée. Mais surtout, la simplicité reste une fonctionnalité. Les bases sont posées et ne bougeront pas de sitôt. Le développement du langage laisse toute la place au développement de l’implémentation et de tout ce qui peut tourner autour.

Brad Fitzpatrick a fait une présentation de Go 1.6 et parle de l’évolution à venir du langage. C’est assez humoristique et instructif. Je vous laisse découvrir.

Changements au niveau de la bibliothèque standard

Aucun au niveau de l’API. Là encore, il s’agit d’une promesse de compatibilité.

HTTP2

Le package net/http (client et serveur) prend en charge HTTP2 de manière transparente.

Performances

Les performances sont légèrement améliorées, en particulier le GC — garbage collector ou ramasse‐miettes — dont les pauses sont de l’ordre de quelques millisecondes, quelle que soit la taille du tas.
Les temps de compilations restent identiques ; toutefois, ils sont toujours supérieurs à la version 1.4 qui était codée en C.

Quelques bibliothèques bénéficient d’un gain significatif de l’ordre de 10 % comme compress/bzip2, compress/gzip, crypto/aes, crypto/elliptic, crypto/ecdsa et sort.

Situation de compétition

Comme chacun sait, un dictionnaire (map) ne doit pas être utilisé en lecture si une goroutine y accède en écriture. Cette erreur est maintenant détectée automatiquement (avant, il fallait lancer le race detector). Attention, le programme va faire un panic ! Il vaut donc mieux lancer le race detector avant de passer une application en 1.6.

Trace d’appel

Lors d’un crash, toutes les goroutines étaient affichées jusqu’à présent. Dorénavant, seule celle qui a planté sera affichée. Pour retrouver le fonctionnement précédent, il faut mettre à jour la variable d’environnement GOTRACEBACK à all.

Tris

Les tris sont légèrement plus rapides. Attention, l’ordre des égalités n’étant jamais garanti, le résultat sera peut‐être différent de la version 1.5. Pour assurer un ordre des égalités constant, il faut utiliser la fonction Stable.

Template

Deux ajouts particulièrement importants avec la possibilité d’éviter les espaces autour des expressions. Le signe - avant ou après va éviter d’avoir des espaces et un saut de ligne avant ou après l’action. Par exemple :

{{23 -}}
<
{{- 45}}

Va donner 23<45

Et une nouvelle action {{block}} associée à la possibilité de redéfinir un modèle nommé qui permet de redéfinir des parties d’un modèle. Pour aller plus loin, on se référera à l’exemple donné dans la documentation.

Autres

On retrouvera un nombre assez important d’ajouts mineurs dans la bibliothèque standard indiqués dans la note de version.

Gestion des dépendances externes ou vendoring

Pour permettre d’inclure les bibliothèques externes utilisées dans le répertoire vendor/, la variable d’environnement GO15VENDOREXPERIMENT en option dans la version 1.5 est maintenant active par défaut.

https://tip.golang.org/cmd/go/#hdr-Vendor_Directories

La spécification d’un lock file pour les paquetages vendor/ est en cours de mise au point et permettra à terme d’être utilisée par go get.

Go 1.7

Les développeurs travaillent maintenant à la version 1.7 qui sortira dans six mois. Ils ont participé à un « ask me anything » instructif sur reddit.

Il n’est pas prévu de modifier quoi que ce soit dans le langage, même s’ils sont tous conscients qu’il n’est pas toujours parfait.

Au niveau de l’implémentation, ils travaillent toujours sur des améliorations du ramasse‐miettes, même si les résultats actuels sont considérés comme largement suffisants.

Au niveau du compilateur, il est question d’utiliser SSA, censé faciliter les optimisations et la taille de l’exécutable. Toutefois, il est assuré que cela ne se fera pas au détriment du temps de compilation (celui‐ci, bien que toujours extrêmement court, a augmenté au moment de la réécriture du compilateur de C en Go).

L’optimisation est donc toujours une priorité pour de nombreux développeurs du langage. Ainsi, par exemple, les pkg/.a seront zippés et la bibliothèque zip sera optimisée.

La stabilité du langage et celle de l’API de la bibliothèque standard, ainsi que les excellentes performances doivent maintenant permettre de travailler sur l’écosystème, les paquetages externes et les outils.

Aller plus loin

  • # merci

    Posté par  . Évalué à 0.

    Merci ! À part les news noyaux, je me demandais s'il y avait encore des gens bien pour poster des news de qualité sur des revolutions du libre.

    Personne pour parler de Puppet ou Ansible ? Et après on sera bien.

    • [^] # Re: merci

      Posté par  (site web personnel) . Évalué à 8.

      des revolutions du libre.

      Simple curiosité, en quoi Go est il une révolution du libre?

      • [^] # Re: merci

        Posté par  (site web personnel) . Évalué à 9.

        Le système de concurrence à base de goroutines et de channels est une façon très élégante de répondre au problèmes de nos ordinateurs actuels (augmentation du nombre de cœurs plutôt que de leur puissance unitaire obligeant à faire du multithreading).

        J'imagine que des langages comme Erlang le faisait déjà, mais c'est Go qui a lancé une la hype là dessus et l'a rendu mainstream (un peu comme node.js avec l'asynchrone alors qu'on pouvait le faire depuis des années avec Twisted en python pour ne citer que lui)

        • [^] # Re: merci

          Posté par  (Mastodon) . Évalué à 3.

          Le système de concurrence à base de goroutines et de channels est une façon très élégante

          Il n'y avait pas un système un peu similaire dans Modula2 ?

          • [^] # Re: merci

            Posté par  . Évalué à 2.

            Je pense que oui, ça fait 20 que j'ai étudié modula 2 donc je n’osais pas intervenir.
            Mais pour moi go ne fait que recycler une techno.
            Pourquoi modula2 n'a pas pris je n'en sais rien (pas assez de pub ?) mais j'ai l'impression qu'on fait du neuf avec du vieux, ce qui est courent en informatique.
            Après ce n'est peut être qu'une question de maturité technologique et une adéquation à son époque.

    • [^] # Re: merci

      Posté par  . Évalué à 5.

      Merci du merci, quand on a le nez dans une dépêche c'est difficile de se rendre compte de ce que ça va donner.
      Je ne pense pas non plus que ce soit une révolution, c'est juste une réponse bien pratique à des problèmes actuels, sans justement se casser la tête à tout réinventer.

      Pour rester dans le sujet et répondre à ta question, une conf intéressante sur le dev de http://ngrok.com
      à la fin il explique pourquoi Go et comment il a essayé de ne pas se perdre dans les dédales de l'orchestration.

      https://www.twilio.com/blog/2016/02/how-alan-shreve-built-ngrok-with-go.html

      24:50 exercice :

      • Ecrire une application web (même petite)
      • Temps réel avec websocket
      • Rapide 1K+ req/s
      • Monte à 10K connections simultanée
      • Exploite tous les coeurs de la machine
      • Déploiement d'un binaire sans dépendance sur différents plateformes

      Le tout en une journée ;-)

      Bon, maintenant que j'ai réussi il ne me reste plus qu'à trouver les clients pour faire les requêtes. La il donne une réponse aussi : vendez ce qui se vend déjà, vous êtes au moins sur que c'est vendable ! Mince c'est toujours pas la révolution non plus…

      • [^] # Re: merci

        Posté par  . Évalué à 5.

        Merci. Je suis en plein refresh de mes compétences (sur un plan personnel), et devant la montée de node.js, je me demandais si j'allais avoir le choix. Finalement, go me semble avoir de l'avenir, une solide base technique, et je déteste la syntaxe JS et sa pauvreté, donc ca peut donner un sérieux challenger.

        Des conseils / retours sur go vs node.js ?

        • [^] # Re: merci

          Posté par  . Évalué à 3.

          L'approche événementielle est complètement différente… Question de goût ou de besoin ?
          Ce qui est marrant c'est qu'on reste en famille, Robert Griesemer a travaillé sur V8 (et java hotspot) avant de participer à la conception Go.
          J'ai la chance de pouvoir choisir un langage parce qu'il me plait plus que par besoin donc je ne pourrai pas t'aider.

        • [^] # Re: merci

          Posté par  (site web personnel) . Évalué à 10. Dernière modification le 21 février 2016 à 13:51.

          Sans être présonptueux, j'ai fait une présentation aux BlendWebMix 2015 que tu peux voir ici:
          https://www.youtube.com/watch?v=95tQaVh9op0

          Si je peux te donner quelques conseils:

          • bien se repencher sur la notion de "pointeur" même si elle est très simple en Go, ça peut vite devenir casse-tête si tu n'as aucune notion dessus
          • éviter au maximum de vouloir reproduire une notion de POO avancée, et se pencher sur le compositing, il y a des ressemblances sans pour autant être des équivalences
          • utiliser le répertoire $GOPATH pour ses projets, sinon on s'arrache les cheveux quand on décide de déporter le développement
          • ne pas user des goroutines pour tout et n'importe quoi

          J'ai beaucoup utilisé nodeJS et je vais te dire ce que je pense du fight Go vs Node:

          • nodejs est super pratique pour avoir un code client et serveur sur le même langage, il peut même permettre de partager du code
          • nodejs est rapidement un énorme "foutoir" de code où on trouve des fonctions imbriquées de partout, et ça devient très vite peu maintenable si, à la base, tu ne te forces pas à de la rigueur
          • Go a pour lui le fait de forcer un code propre (on peut faire dégueux, mais c'est pas simple :)) - les warning sont des erreurs, tu peux pas laisser des packages non utilisés ou des variables non utilisées, ça te permet de faire franchement moins de bordel
          • Niveau perf, Go et NodeJs sont (de manière surprenante) assez proche finalement… NodeJS est franchement performant, mais Go a un avantage: tu compiles en natif "statique". Donc pas d'installation à faire sur le serveur de production
          • les goroutines sont bien plus simples à appréhender, selon moi, que les principe de "promesses" en JS

          Voilà…

          • [^] # Re: merci

            Posté par  . Évalué à 4.

            Super ta présentation aux BlendWebMix, tu fais bien ressortir le côté simple et ludique de Go.

            Je vais aller voir ton framework, si tu pouvais en faire un journal ou une dépêche pour nous expliquer comment il fonctionne, pourquoi tu en a créé un nouveau etc ce serait génial.

          • [^] # Re: merci

            Posté par  (Mastodon) . Évalué à 2.

            Merci Patrice pour le lien vers ta présentation, ça change des présentations en anglais ;-)
            J'ai profité de la présentation pour regarder le projet https://github.com/kwiscale/framework et je me demandais quels sont les avantages de ton framework par rapport aux autres plus répandus ?

  • # Nombre de goroutine

    Posté par  . Évalué à 6. Dernière modification le 21 février 2016 à 16:01.

    Merci pour cet article.

    on peut en lancer des milliers, réparties automatiquement sur plusieurs threads ou cœurs.
    

    Plutôt que de retenir une limite haute pour le nombre de goroutine, il faut plutôt dire que le nombre de goroutine est rarement le facteur limitant, si c'est goroutine sont en attente par exemple de paquets réseau.

    Il y a une vidéo de Rob Pike (que je n'arrive plus à retrouver) où il indique qu'il est courant de voir des serveurs de production chez Google avec des centaines de milliers voire des millions de goroutine.

    Ce billet de chez Cloudflare montre que leur serveur DNS (écrit en Go) lance 40k goroutines sans souci particulier autres que des stacks montreuse :)

    Personnellement, pour certains cas particuliers, il m'arrive de lancer des centaines de milliers de goroutine sans problème.

    La taille minimale de la stack d'une goroutine est de 2ko qui est donc bcp plus petite que celle d'un thread.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.